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(54) A CAN device featuring advanced Can filtering and message acceptance 

ignated to be the matching message object. 



(57) A CAN device that supports a plurality n (where 
n £ 3) of message objects, including a plurality of regis- 
ters associated with each message object, including at 
least one object match ID register that contains a multi- 
bit object match ID field, and at least one object mask 
register that contains a multi-bit object mask field; and, 
a CAN/CAL module that processes incoming mes- 
sages. The CAN/CAL module assembles a multi-bit 
screener ID from selected bits of each incoming mes- 
sage to be acceptance filtered, compares the bits com- 
prising the screener ID with corresponding bits of the 
object match ID field associated with each of at least 
designated ones of the plurality n of message objects, 
disregarding any bits of each object match ID field that 
are masked by corresponding bits of the associated 
object mask field, and then determines whether any of 
the comparisons results in a match. Any selected one or 
more bits of the object match ID field associated with 
each of the plurality n of message objects can be set'to 
*1 1 or '0', and any selected one or more bits of the object 
mask field associated with each of the plurality n of 
message objects can be set to '1 ' or '0' in order to mask 
any selected one or more bits of the associated object 
match ID field, whereby the combination of the object 
match ID field and the object mask field associated with 
each of the plurality n of message objects constitutes a 
fully programmable match and mask filter. The 
CAN/CAL module has the capability to perform accept- 
ance filtering on incoming messages constituting either 
standard or extended CAN frames. If more than one 
match is detected, a lowest-numbered (or, alternatively, 
highest-numbered) one of the message objects is des- 
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Description 

[0001] This application claims the full benefit and 
priority of U.S. Provisional Application Serial Number 
60/154,022, filed on September 15, 1999, the disclo- 
sure of which is fully incorporated herein for all pur- 
poses. 

BACKGROUND OF THE INVENTION 

[0002] The present invention relates generally to 
the field of data communications, and more particularly, 
to the field of serial communications bus controllers and 
microcontrollers that incorporate the same. 
[0003] CAN (Control Area Network) is an industry- 
standard, two-wire serial communications bus that is 
widely used in automotive and industrial control applica- 
tions, as well as in medical devices, avionics, office 
automation equipment, consumer appliances, and 
many other products and applications. CAN controllers 
are currently available either as stand-alone devices 
adapted to interface with a microcontroller or as circuitry 
integrated into or modules embedded in a microcontrol- 
ler chip. Since 1986, CAN users (software program- 
mers) have developed numerous high-level CAN 
Application Layers (CALs) which extend the capabilities 
of the CAN while employing the CAN physical layer and 
the CAN frame format, and adhering to the CAN speci- 
fication. CALs have heretofore been implemented pri- 
marily in software, with very little hardware CAL 
support. Consequently, CALs have heretofore required 
a great deal of host CPU intervention, thereby increas- 
ing the processing overhead and diminishing the per- 
formance of the host CPU. 

[0004] Thus, there is a need in the art for a CAN 
hardware implementation of CAL functions normally 
implemented in software in order to offload these tasks 
from the host CPU to the CAN hardware, thereby ena- 
bling a great savings in host CPU processing resources 
and a commensurate improvement in host CPU per- 
formance. One of the most demanding and CPU 
resource-intensive CAL functions is message manage- 
ment, which entails the handling, storage, and process- 
ing of incoming CAL/CAN messages received over the 
CAN serial communications bus and/or outgoing 
CAL7CAN messages transmitted over the CAN serial 
communications bus. CAL protocols, such as. Device- 
Net, CANopen, and OSEK, deliver long messages dis- 
tributed over many CAN frames, which methodology is 
sometimes referred to as "fragmented" or "segmented" 
messaging. The process of assembling such frag- 
mented, multi-frame messages has heretofore required 
a great deal of host CPU intervention. In particular, CAL 
software running on the host CPU actively monitors and 
manages the buffering and processing of the message 
data, in order to facilitate the assembly of the message 
fragments or segments into complete messages. 
[0005] Based on the above and foregoing, it can be 
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appreciated that there presentl^xists a need in the art 
for a hardware implementation of CAL functions nor- 
mally implemented in software in order to offload these 
tasks from the host CPU, thereby enabling a great sav- 

5 ings in host CPU processing resources and a commen- 
surate improvement in host CPU performance. 
[0006] The assignee of the present invention has 
recently developed a new microcontroller product, des- 
ignated "XA-C3", that fulfills this need in the art. The 

10 XA-C3 is the newest member of the Philips XA 
(extended Architecture) family of high performance 16- 
bit single-chip microcontrollers. It is believed that the 
XA-C3 is the first chip that features hardware CAL sup- 
port. 

is [0007] The XA-C3 is a CMOS 1 6-bit CAI7CAN 2.0B 
microcontroller that incorporates a number of different 
inventions, including the present invention. These 
inventions include novel techniques and hardware for fil- 
tering, buffering, handling, and processing CAL/CAN 

20 messages, including the automatic assembly of multi- 
frame fragmented messages with minimal CPU inter- 
vention, as well as for managing the storage and 
retrieval of the message data, and the memory 
resources utilized therefor. 

25 [0008] The present invention relates to a CAN 
microcontroller that supports a plurality (e.g., 32) of 
message objects, each one of which is assigned a 
respective message buffer within an on-chip and/or off- 
chip portion of the overall data memory space of the 

30 CAN microcontroller. The location and size of each of 
the message buffers can be reconfigured by the user 
(programmer) by simple programming of memory- 
mapped registers provided for this purpose. The mes- 
sage buffers are used to store incoming (receive) mes- 
as sages and to stage outgoing (transmit) messages. With 
the XA-C3 microcontroller that constitutes a presently 
preferred implementation of the present invention, 
Direct Memory Access (DMA) is employed to enable the 
XA-C3 CAN module to directly access any of the 32 

40 message buffers without interrupting the processor 
core. This message storage scheme provides a great 
deal of flexibility to the user, as the user is free to use as 
much or as little message storage area as an applica- 
tion requires, and is also free to position the message 

45 buffers wherever it is most convenient 

[0009] This message storage scheme is a key ele- 
ment of the unique ■message-management" capabilities 
of the XA-C3 CAN microcontroller, as this scheme ena- 
bles the XA-C3 CAN/CAL module to concurrently 

so assemble many (up to 32) incoming, fragmented mes- 
sages of varying lengths, and, at the same time, stage 
multiple outgoing messages for transmission. Since 
incoming message assembly is handled entirely in 
hardware, the processor is free to perform other tasks, 

55 typically until a complete message is received and 
ready for processing. 

[0010] All CAN devices have the ability to perform 
receive acceptance filtering or screening. Acceptance 
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filtering is typically accomplished by comparing informa- 
tion in the header portion of a received CAN message to 
be filtered or screened (and, in some cases, also the 
first and/or second byte in the data field of the received 
CAN message) to one or more pre-established values, 5 
sometimes called acceptance filters or screeners. Soft- 
ware running on the processor core can perform the 
acceptance filtering at the expense of performance, 
because software requires an ample amount of CPU 
resources and time to perform acceptance filtering, w 
Therefore, hardware filtering is desired in order to 
reduce the burden or overhead processing load on the 
CPU (processor core). However, with the presently 
available technology, hardware filtering is far less flexi- 
ble than software filtering, and greatly increases the 75 
required die area for implementation of the CAN device. 
[0011] The presently available acceptance filtering 
techniques include the use of a match field and a mask 
field to create what is sometimes referred to as a "match 
and mask" filter. Each combination of available match 20 
and mask fields constitutes a separate filter or filter 
object. A basic CAN device will typically have one or two 
filters with full match and mask capabilities. A whole 
family of messages will typically be accepted. Software 
or hardware can be employed to actually perform the fil- 25 
tering. However, with the presently available technology, 
software must decide where to store each individual 
message. This type of filtering is generally the most flex- 
ible; however, it consumes the most CPU resources. 
[0012] A full CAN device is one in which the hard- 30 
ware filters a message and matches it to one of a 
number of screeners to decide where to store the mes- 
sage. Each filter is linked to a message buffer. Upon a 
successful comparison of the incoming message 
header to one of the screeners, the message is stored 35 
in the message buffer associated with the matching 
screener. Generally, only "matching" and not "masking" 
is performed by each filter. However, there could be a 
■global mask" that is applied to all filters, or one filter 
could be designated to provide the "mask". 40 
[0013] Based on the above and foregoing, it can be 
appreciated that there presently exists a need in the art 
for a much more flexible and powerful technique for 
message acceptance filtering in a CAN device, e.g., a 
CAN microcontroller, that overcomes the above-dis- 45 
cussed limitations and shortcomings of the presently 
available technology, particularly such a techniqueihat 
does not explode the required die area to implement the 
CAN device, and which is performed in hardware, rather 
than software, to thereby minimize loading of the proc- 50 
essor (CPU) core, and thereby dramatically improve 
system performance. 

[0014] The present invention fulfills this need in the 
art. As will become apparent hereinafter, the preferred 
implementation of the present invention in the XA-C3 55 
microcontroller provides 32 fully programmable match 
and mask filters, which affords a much more powerful 
system than is possible with the presently available 
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technology, without loading^he processor core. The 
user can define and dedicate filters to a wide variety of 
messages without running out This is especially useful 
for systems that need to dedicate filters to system man- 
agement functions, such as unconnected message 
management, explicit I/O and Dup MAC used in the 
CAN protocol DeviceNet 

[0015] Most existing CAN devices can After on an 
1 1-bit CAN identifier (standard CAN frames) or a 29-bit 
CAN identifier (extended CAN frames). However, each 
of the 32 filters in the XA-C3 microcontroller can be indi- 
vidually configured to filter on either the 11 -bit CAN 
identifier of standard CAN frames or the 29-bit CAN 
identifier of extended CAN frames. This allows for a sys- 
tem with mixed CAN devices and provides maximum 
flexibility. 

[0016] Further, the XA-C3 microcontroller provides 
filtering that goes beyond the CAN specification. More 
particularly, in addition to filtering on the CAN identifier, 
the XA-C3 microcontroller permits filtering on the first 
and/or second data bytes of the data field of incoming 
CAN frames. This is a very useful feature for higher level 
CAN protocols such as DeviceNet, CanOpen, and 
Osek, which have traditionally required software to fitter 
on the first two bytes of the data field. 
[0017] Yet further, the XA-C3 microcontroller pro- 
vides for masking on every bit on every filter (with the 
exception of the IDE bit). Traditional CAN devices have 
only provided a subset of this capability, allowing only 
global masking which is applied to all of the filter 
objects, or dedicating one or two objects to have the 
fully masking capability. No presently available device 
provides for full masking on every filter. This feature is 
extremely useful to a user that wants to define and 
receive families of messages under both the standard 
CAN specification and the higher level protocols such 
as DeviceNet, CanOpen, and Osek. 
[0018] Additionally, the XA-C3 microcontroller pro- 
vides for masking on the RTR bit in the CAN header, 
thereby allowing the device to receive and recognize an 
RTR frame. In this connection, the user can dedicate a 
filter object exclusively for the purpose of monitoring an 
RTR frame and/or sending out RTR frames. 

SUMMARY OF THE INVENTION 

[0019] The present invention, encompasses, in one 
of its aspects, a CAN device that supports a plurality n 
(where n > 3) of message objects, including a plurality of 
registers associated with each message object, includ- 
ing at least one object match ID register that contains a 
multi-bit object match ID field, and at least one object 
mask register that contains a multi-bit object mask field; 
and, a CAN/CAL module that processes incoming mes- 
sages. The CAN/CAL module assembles a multi-bit 
screener ID from selected bits of each incoming mes- 
sage to be acceptance filtered, compares the bits com- 
prising the screener ID with corresponding bits of the 
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object match ID field associated with each of at least 
designated ones of the plurality n of message objects, 
disregarding any bits of each object match ID field that 
are masked by corresponding bits of the associated 
object mask field, and then determines whether any of 5 
the comparisons results in a match. Any selected one or 
more bits of the object match ID field associated with 
each of the plurality n of message objects can be set to 
'1 ' or '0\ and any selected one or more bits of the object 
mask field associated with each of the plurality n of w 
message objects can be set to 'V or '0' in order to mask 
any selected one or more bits of the associated object 
match ID field, whereby the combination of the object 
match ID field and the object mask field associated with 
each of the plurality n of message objects constitutes a 75 
fully programmable match and mask filter. The 
CAN/CAL module has the capability to perform accept- 
ance filtering on incoming messages constituting either 
standard or extended CAN frames, if more than one 
match is detected, a lowest-numbered (or, alternatively, 20 
highest-numbered) one of the message objects is des- 
ignated to be the matching message object. 
[0020] In a presently preferred embodiment, the 
plurality of registers further include an RTR register 
associated with each message object. The RTR register 25 
associated with each message object contains an RTR 
handling enable field that is programmable for the pur- 
pose of enabling or disabling the associated message 
object to detect receipt of an incoming message that 
constitutes an Remote Transmit Request frame and/or 30 
to transmit a Remote Transmit Request frame. Prefera- 
bly, an incoming message for which a match is detected 
is stored by a DMA engine in the message buffer asso- 
ciated with the matching message object. 
[0021] In another of its aspects, the present inven- 35 
tion encompasses a CAN microcontroller that includes, 
in addition to the above-described registers (which are 
preferably implemented as memory-mapped registers 
in the microcontroller data memory space) and the 
above-described CAN/CAL module, a processor core 40 
that runs CAN applications, and a DMA engine that ena- 
bles the CAN/CAL module to directly access the mes- 
sage buffers, e.g., for storage and retrieval of 
messages. 

[0022] In yet another of its aspects, the present 45 
invention encompasses, in a CAN device that supports 
a plurality n (where n £ 3) of message objects-each of 
which has an associated message buffer, at least one 
associated match ID register, and at least one associ- 
ated mask register, a method for acceptance filtering so 
incoming CAN frames. The method includes the steps 
of programming the at least one match ID register asso- 
ciated with each of at least designated ones of the mes- 
sage objects by selectively setting each of the bits in a 
multi-bit match ID field contained therein to "1 1 or '0'; pro- 55 
gramming the at least one mask register associated 
with each of the at least designated ones of the mes- 
sage objects by selectively setting each of the bits in a 
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multi-bit mask field contained merein to '1 ' or '0'; extract- 
ing a multi-bit screener ID field from a received CAN 
frame; and, comparing the extracted screener ID field to 
the multi-bit match ID field stored in the at least one 
match ID register associated with each of the at least 
designated ones of the message objects, excluding 
from the comparison any bits of the match ID field 
masked by corresponding bits of the associated mask 
field stored in the at least one associated mask register. 
If a match if found as a result of the comparing step, the 
method further includes the step of storing data bytes of 
the received CAN frame in the message buffer associ- 
ated with the matching message object. In an embodi- 
ment of the CAN device according to the invention: 

a received message to be acceptance filtered com- 
prises a standard CAN frame; and, 
the screener ID field comprises 1 1 bits of a CAN ID 
field of a header portion of the standard CAN frame, 
8 bits of a first data byte of the standard CAN frame, 
8 bits of a second data byte of the standard CAN 
frame, two dont care bits, and an IDE bit. 

[0023] In an embodiment of the CAN device 
according to the invention the IDE bit is not maskable, 
and the two don't care bits are required to be masked. 
[0024] In an embodiment of the CAN device 
according to the invention: 

a received message to be acceptance filtered com- 
prises an extended CAN frame; and, 
the screener ID field comprises 29 bits of a CAN ID 
field of a header portion of the standard CAN frame, 
and an IDE bit. 

[0025] In an embodiment of the CAN device 
according to the invention the IDE bit is not maskable. 
[0026] In an embodiment of the CAN device 
according to the invention the CAN/CAL module has the 
capability to perform acceptance filtering on incoming 
messages comprising either standard or extended CAN 
frames. 

In an embodiment of the CAN device according to the 
invention the plurality of registers further include a con- 
trol register associated with each message object, 
wherein the control register associated with each mes- 
sage object- contains an object enable field that is pro- 
grammable for the purpose of enabling or disabling the 
associated message object 

[0027] In an embodiment of the CAN device 
according to the invention the control register associ- 
ated with each message object further contains an 
object designation field that is programmable for the 
purpose of designating the associated message object 
as a receive or transmit message object, whereby the 
designated ones of the plurality n of message objects 
comprise all message objects that have been enabled 
and designated as a receive message object. 



4 



EP 1 085 720 A2 



[0028] In an embodiment of the CAN device 
according to the invention: 

the message objects are uniquely numbered; and, 
if more than one match is detected, designating a s 
lowest-numbered one of the message objects to be 
the matching message object. 

[0029] In an embodiment of the CAN device 
according to the invention the plurality of registers fur- w 
ther include an RTR register associated with each mes- 
sage object, wherein the RTR register associated with 
each message object contains an RTR handling enable 
field that is programmable for the purpose of enabling or 
disabling the associated message object to detect 15 
receipt of an incoming message that comprises an 
Remote Transmit Request frame and/or to transmit a 
Remote Transmit Request frame. 
[0030] In an embodiment of the CAN device 
according to the invention: 20 

the CAN/CAL module has the capability of automat- 
ically assembling incoming messages that com- 
prise multi-frame, fragmented messages; 
the plurality of registers further include a frag- 25 
mented message handling enable register associ- 
ated with each message object, wherein the 
fragmented message handling enable register 
associated with each message object contains a 
fragmented message handling enable field that is 30 
programmable for the purpose of enabling or disa- 
bling the associated message object to receive 
multi-frame, fragmented messages for automatic 
assembly by the CAN/CAL module; and, 
all of the designated ones of the plurality n of mes- 35 
sage objects are disabled to receive multi-frame, 
fragmented messages, and thus, are enabled only 
to receive single-frame, non-fragmented mes- 
sages. In an embodiment of the CAN device 
according to the invention the plurality of registers ao 
comprise memory-mapped registers. 

[0031] An embodiment of the CAN device accord- 
ing to the invention further comprises a data memory 
space, wherein the plurality of memory-mapped regis- as 
ters are mapped to a respective portion of the data 

memory space. 

[0032] An embodiment of the CAN device accord- 
ing to the invention further comprising a data memory 
space, wherein the plurality of memory-mapped regis- so 
ters are mapped to a respective dedicated RAM portion 
of the data memory space. 

[0033] An embodiment of the CAN device accord- 
ing to the invention further comprises: 

ss 

a data memory space; 

a plurality of message buffers associated with 
respective ones of the message objects, the plural- 
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ity of message buff e toeing located in the data 
memory space; 

a DMA engine that enables the CAN/CAL module 
to directly access the message buffers. 

[0034] In an embodiment of the CAN device 
according to the invention the plurality of memory- 
mapped registers are mapped to a respective portion of 
the data memory space. 

[0035] In an embodiment of the CAN device 
according to the invention the plurality of memory- 
mapped registers are mapped to a respective dedicated 
RAM portion of the data memory space. 
[0036] In an embodiment of the CAN device 
according to the invention the CAN device is a CAN 
microcontroller. 

[0037] An embodiment of the CAN device accord- 
ing to the invention further comprising a processor core 
that runs CAN applications. 

[0038] An embodiment of the CAN device accord- 
ing to the invention further comprises: 

a data memory space; 

a plurality of message buffers associated with 
respective ones of the message objects, the plural- 
ity of message buffers being located in the data 
memory space; 

a DMA engine that enables the CAN/CAL module 
to directly access the message buffers without 
interrupting the processor core. 

[0039] In an embodiment of the CAN device 
according to the invention an incoming message for 
which a match is detected is stored by the DMA engine 
in the message buffer associated with the matching 
message object. 

[0040] In an embodiment of the CAN device 
according to the invention: 

the message objects are uniquely numbered; and, 
if more than one match is detected, designating a 
lowest-numbered one of the message objects to be 
the matching message object 

[0041] In an embodiment of the CAN device 
according to the invention an incoming message for 
which a match is detected is stored by- the DMA engine 
in the message buffer associated with the matching 
message object. 

[0042] In an embodiment of the CAN device 
according to the invention: 

the message objects are uniquely numbered; and, 
if more than one match is detected, designating a 
lowest-numbered one of the message objects to be 
the matching message object 
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[0043] These and various other aspects, features, 
and advantages of the present invention will be readily 
understood with reference to the following detailed 5 
description of the invention read in conjunction with the 
accompanying drawings, in which: 

FIG. 1 is a diagram illustrating the format of a 
Standard CAN Frame and the format of an w 
Extended CAN Frame; 

FIG. 2 is a diagram illustrating the interleaving of 
CAN Data Frames of different, unrelated mes- 
sages; 

FIG. 3 is a high-level, functional block diagram of 15 
the XA-C3 microcontroller; 
FIG. 4 is a table listing all of the Memory Mapped 
Registers (MMRs) provided by the XA-C3 micro- 
controller; 

FIG. 5 is a diagram illustrating the mapping of the 20 
overall data memory space of the XA-C3 microcon- 
troller; 

FIG. 6 is a diagram illustrating the MMR space con- 
tained within the overall data memory space of the 
XA-C3 microcontroller; 25 
FIG. 7 is a diagram illustrating formation of the base 
address of the on-chip XRAM of the XA-C3 micro- 
controller, with an object n message buffer mapped 
into off-chip data memory; 

FIG. 8 is a diagram illustrating formation of the base 30 
address of the on-chip XRAM of the XA-C3 micro- 
controller, with an object n message buffer mapped 
into the on-chip XRAM; 

FIG. 9 is a diagram illustrating the Screener ID Field 
for a Standard CAN Frame; 35 
FIG. 10 is a diagram illustrating the Screener ID 
Field for an Extended CAN Frame; 
FIG. 11 is a diagram illustrating the message stor- 
age format for fragmented CAL messages; and, 
FIG. 12 is a diagram illustrating the message stor- 40 
age format for fragmented CAN messages. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

45 

[0044] The present invention is described below in 
the context of a particular implementation thereof, i.e., 
in the context of the XA-C3 microcontroller manufac- 
tured by Philips Semiconductors. Of course, it should be 
clearly understood that the present invention is not lim- so 
ited to this particular implementation, as any one or 
more of the various aspects and features of the present 
invention disclosed herein can be utilized either individ- 
ually or any combination thereof, and in any desired 
application, e.g., in a stand-alone CAN controller device 55 
or as part of any other microcontroller or system. 
[0045] The following terms used herein in the con- 
text of describing the preferred embodiment of the 



present invention (i.e., the XA 
defined as follows: 



XA^3 



microcontroller) are 



Standard CAN Frame: The format of a 

Standard CAN Frame is depicted in FIG. 1 . 

Extended CAN Frame: The format of an 

Extended CAN Frame is also depicted in FIG. 1. 

Acceptance Filtering: The process a CAN 

device implements in order to determine "rf a CAN 
frame should be accepted or ignored and, if 
accepted, to store that frame in a pre-assigned 
Message Object. 

Message Object: A Receive RAM buffer of 
pre-specified size (up to 256 bytes for CAL mes- 
sages) and associated with a particular Acceptance 
Rlter or, a Transmit RAM buffer which the User 
preloads with all necessary data to transmit a com- 
plete CAN Data Frame. A Message Object can be 
considered to be a communication channel over 
which a complete message, or a succession of 
messages, can be transmitted. 

CAN Arbitration ID: An 11 -bit (Standard 

CAN 2.0 Frame) or 29-bit (Extended CAN 2.0B 
Frame) identifier field placed in the CAN Frame 
Header. This ID field is used to arbitrate Frame 
access to the CAN bus. Also used in Acceptance 
Filtering for CAN Frame reception and Transmit 
Pre-Arbitration. 

Screener ID: A 30-b'rt field extracted from 

the incoming message which is then used in 
Acceptance Filtering. The Screener ID includes the 
CAN Arbitration ID and the IDE bit, and can include 
up to 2 Data Bytes. These 30 extracted bits are the 
information qualified by Acceptance Filtering. 

Match ID: A 30-bit field pre-specified by the 
user to which the incoming Screener ID is com- 
pared. Individual Match IDs for each of 32 Message 
Objects are programmed by the user into desig- 
nated Memory Mapped Registers (MMRs). 

Mask: A 29-bit field pre-specified by-the user 
which can override (Mask) a Match ID comparison 
at any particular bit (or, combination of bits) in an 
Acceptance Filter. Individual Masks, one for each 
Message Object, are programmed by the user in 
designated MMRs. Individual Mask patterns assure 
that single Receive Objects can Screen for multiple 
acknowledged CAL/CAN Frames and thus mini- 
mize the number of Receive Objects that must be 
dedicated to such lower priority Frames. This ability 
to Mask individual Message Objects is an impor- 
tant new CAL feature. 
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CAL: CAN Application Layer. A generic term 
for any high-level protocol which extends the capa- 
bilities of CAN while employing the CAN physical 
layer and the CAN frame format, and which 
adheres to the CAN specification. Among other 5 
things, CALs permit transmission of Messages 
which exceed the 8 byte data limit inherent to CAN 
Frames. This is accomplished by dividing each 
message into multiple packets, with each packet 
being transmitted as a single CAN Frame consist- 10 
ing of a maximum of 8 data bytes. Such messages 
are commonly referred to as "segmented* or frag- 
mented" messages. The individual CAN Frames 
constituting a complete fragmented message are 
not typically transmitted in a contiguous fashion, 15 
but rather, the individual CAN Frames of different, 
unrelated messages are interleaved on the CAN 
bus, as is illustrated in FIG. 2 

Fragmented Message: A lengthy message 20 
(in excess of 8 bytes) divided into data packets and 
transmitted using a sequence of individual CAN 
Frames. The specific ways that sequences of CAN 
Frames construct these lengthy messages is 
defined within the context of a specific CAL. The 25 
XA-C3 microcontroller automatically re-assembles 
these packets into the original, lengthy message in 
hardware and reports (via an interrupt) when the 
completed (re-assembled) message is available as 
an associated Receive Message Object. 30 

Message Buffer: A block of locations in XA 
Data memory where incoming (received) mes- 
sages are stored or where outgoing (transmit) mes- 
sages are staged. 35 

MMR: Memory Mapped Register. An on- 

chip command/control/status register whose 
address is mapped into XA Data memory space 
and is accessed as Data memory by the XA proces- 40 
sor. With the XA-C3 microcontroller, a set of eight 
dedicated MMRs are associated with each Mes- 
sage Object. Additionally, there are several MMRs 
whose bits control global parameters that apply to 
ail Message Objects. 45 

[0046] With reference now to FIG. 3, there can be 
seen a high-level block diagram of the XA-C3 microcon- 
troller 20. The XA-C3 microcontroller 20 includes the 
following functional blocks that are fabricated on a sin- so 
gle integrated circuit (IC) chip packaged in a 44-pin 
PLCC or a 44-pin LQFP package: 

an XA CPU Core 22, that is currently implemented 
as a 1 6-brt fully static CPU with 24-bit program and 55 
data address range, that is upwardly compatible 
with the 80C51 architecture, and that has an oper- 
ating frequency of up to 30 MHz; 
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a program or code memory 24 that is currently 
implemented as a 32K ROM/EPROM, and that is 
bi-directionally coupled to the XA CPU Core 22 via 
an internal Program bus 25. A map of the code 
memory space is depicted in FIG. 4; 

a Data RAM 26 (internal or scratch pad data mem- 
ory) that is currently implemented as a 1024 Byte 
portion of the overall XA-C3 data memory space, 
and that is bi-directionally coupled to the XA CPU 
Core 22 via an internal DATA bus 27; 

an on-chip message buffer RAM or XRAM 28 that is 
currentJy implemented as a 512 Byte portion of the 
overall XA-C3 data memory space which may con- 
tain part or all of the CAN/CAL (Transmit & Receive 
Object) message buffers; 

a Memory Interface (MIF) unit 30 that provides 
interfaces to generic memory devices such as 
SRAM, DRAM, flash, ROM, and EPROM memory 
devices via an external address/data bus 32, via an 
internal Core Data bus 34, and via an internal MMR 
bus 36; 

a DMA engine 38 that provides 32 CAL DMA Chan- 
nels; 

a plurality of on-chip Memory Mapped Registers 
(MMRs) 40 that are mapped to the overall XA-C3 
data memory space - - a 4K Byte portion of the 
overall XA-C3 data memory space is reserved for 
MMRs. These MMRs include 32 (Message) Object 
or Address Pointers and 32 ID Screen ers or Match 
IDs, corresponding to the 32 CAL Message 
Objects. A complete listing of all MMRs is provided 
in the Table depicted in FIG. 5; 

a 2.0B CAN/DLL Core 42 that is the CAN Controller 
Core from the Philips SJA 1 000 £AN (2.0A/B) JQata 
Link Layer (CDLL) device (hereinafter referred to as 
the "CAN Core Block" (CCB)); and, 

an array of standard microcontroller peripherals 
that are bi-directionally coupled to the XA CPU 
Core 22 via a Special Eunction Register (SFR) bus 
43. These- standard, microcontroller peripherals 
include Universal Asynchronous Receiver Trans- 
mitter (UART) 49, an SPI serial interface (port) 51, 
three standard timers/counters with toggle output 
capability, namely, Timer 0 & Timer 1 included in 
Timer block 53, and Timer 2 included in Timer block 
54, a Watchdog Timer 55, and four 8-b'rt I/O ports, 
namely, Ports 0-3 included in block 61, each of 
which has 4 programmable output configurations. 

[0047] The DMA engine 38, the MMRs 40, and the 
CCB 42 can collectively be considered to constitute a 
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CAN/CAL module 77, and will be referred to as such at 
various times throughout the following description. Fur- 
ther, the particular logic elements within the CAN/CAL 
module 77 that perform "message management" and 
"message handling" functions will sometimes be 5 
referred to as the "message management engine" and 
the "message handler", respectively, at various times 
throughout the following description. Other nomencla- 
ture will be defined as it introduced throughout the fol- 
lowing description. 10 
[0048] As previously mentioned, the XA-C3 micro- 
controller 20 automatically implements, in hardware, 
many message management and other functions that 
were previously only implemented in software running 
on the host CPU (or not implemented at ail), including is 
transparent, automatic re-assemb!y of up to 32 concur- 
rent, interleaved, multi-frame, fragmented CAL mes- 
sages. For each application that is installed to run on 
the host CPU (i.e., the XA CPU Core 22), the user (soft- 
ware programmer) must set-up the hardware for per- 20 
forming these functions by programming certain ones of 
the MMRs and SFRs in the manner set forth in the XA- 
C3 Functional Specification and XA-C3 CAN Transport 
Layer Controller User Manual. The register program- 
ming procedures that are most relevant to an under- 25 
standing of the present invention are described below, 
followed by a description of the various message man- 
agement and other functions that are automatically per- 
formed by the CAL/CAN module 77 during operation of 
the XA-C3 microcontroller 20 after it has been properly 30 
set-up by the user. Following these sections, a more 
detailed description of the particular invention to which 
this application is directed is provided. 
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Set-up/Programming Procedures 
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[0049] As an initial matter, the user must map the 
overall XA-C3 data memory space, as illustrated in FIG. 
5. In particular, subject to certain constraints, the user 
must specify the starting or base address of the XRAM 40 
28 and the starting or base address of the MMRs 40. 
The base address of the MMRs 40 can be specified by 
appropriately programming Special Function Registers 
(SFRs) MRBL and MRBH. The base address of the 
XRAM 28 can be specified by appropriately program- 45 
ming the MMRs designated MBXSR and XRAMB (see 
FIG. 4). 

[0050] The user can place the 4KByte space 
reserved for MMRs 40 anywhere within the entire 16 
Mbyte data memory space supported by the XA archi- so 
tecture, other than at the very bottom of the memory 
space (i.e., the first 1 KByte portion, starting address of 
OOOOOOh), where it would conflict with the on-chip Data 
RAM 26 that serves as the internal or scratch-pad mem- 
ory. The 4KBytes of MMR space will always start at a 4K ss 
boundary. The reset values for MRBH and MRBL are 
OFh and FOh, respectively. Therefore, after a reset, the 
MMR space is mapped to the uppermost 4K Bytes of 



Data Segment OFh, but accessto the MMRs 40 is disa- 
bled. The first 512 Bytes (offset OOOh - 1 FFh) of MMR 
space are the Message Object Registers (eight per 
Message Object) for objects n = 0 * 31 , as is shown in 
FIG. 6. 

[0051] The base address of the XRAM 28 is deter- 
mined by the contents of the MMRs designated MBXSR 
and XRAMB, as is shown in FIGs. 7 and 8. As previ- 
ously mentioned, the 51 2 Byte XRAM 28 is where some 
(or all) of the 32 (Rx/Tx) message buffers (correspond- 
ing to Message Objects n = 0 - 31) reside. The message 
buffers can be extended off-chip to a maximum of 8 
KBytes. This off-chip expansion capability can accom- 
modate up to thirty-two, 256-Byte message buffers. 
Since the uppermost 8 bits of all message buffer 
addresses are formed by the contents of the MBXSR 
register, the XRAM 28 and ail 32 message buffers must 
reside in the same 64K Byte data memory segment. 
Since the XA-C3 microcontroller 20 only provides 
address lines A0-A1 9 for accessing external memory, 
all external memory addresses must be within the low- 
est 1MByte of address space. Therefore, if there is 
external memory in the system into which any of the 32 
message buffers will be mapped, then all 32 message 
buffers and the XRAM 28 must also be mapped entirely 
into that same 64K Byte segment, which must be below 
the 1 MByte address limit 

[0052] After the memory space has been mapped, 
the user can set-up or define up to 32 separate Mes- 
sage Objects, each of which can be either a Transmit 
(Tx) or a Receive (Rx) Message Object. A Rx Message 
Object can be associated either with a unique CAN ID, 
or with a set of CAN IDs which share certain ID bit 
fields. As previously mentioned, each Message Object 
has its own reserved block of data memory space (up to 
256 Bytes), which is referred to as that Message 
Object's message buffer. As will be seen, both the size 
and the base address of each Message Object's mes- 
sage buffer is programmable. 

[0053] As previously mentioned, each Message 
Object is associated with a set of eight MMRs 40 dedi- 
cated to that Message Object. Some of these registers 
function differently for Tx Message Objects than they do 
for Rx Message Objects. These eight MMRs 40 are des- 
ignated "Message Object Registers" (see FIG. 4). 
[0054] The names of these eight MMRs 40 are: 

MnMIDH Message n Match ID High 

MnMIDL Message n Match ID Low 

MnMSKH Message n Mask High 

MnMSKL Message n Mask Low 

MnCTL Message n Control 

MnBLR Message n Buffer Location Register 

MnBSZ Message n Buffer Size 

MnFCR Message n Fragment Count Register 

where n ranges from 0 to 31 (i.e., corresponding to 32 
independent Message Objects). 
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[0055] In general, the user defines or sets up a 
Message Object by configuring (programming) some or 
all of the eight MMRs dedicated to that Message Object, 
as will be described below. Additionally, as will be 
described below, the user must configure (program) the 5 
global GCTL register, whose bits control global parame- 
ters that apply to all Message Objects. 
[0056] In particular, the user can specify the Match 
ID value for each Message Object to be compared 
against the Screener IDs extracted from incoming CAN 10 
Frames for Acceptance Filtering. The Match ID value for 
each Message Object n is specified in the MnMIDH and 
MnMIDL registers associated with that Message Object 
n. The user can mask any Screener ID bits which are 
not intended to be used in Acceptance Filtering, on an is 
object-by-object basis, by writing a logic T in the 
desired (to-be-masked) bit position(s) in the appropriate 
MnMSKH and/or MnMSKL registers associated with 
each particular Message Object n. The user is respon- 
sible, on set-up, for assigning a unique message buffer 20 
location for each Message Object n. In particular, the 
user can specify the least significant 1 6 bits of the base 
address of the message buffer for each particular Mes- 
sage Object n by programming the MnBLR register 
associated with that Message Object n. The upper 8 bits 25 
of the 24-bit address, for ail Message Objects, are spec- 
ified by the contents of the MBXSR register, as previ- 
ously discussed, so that the message buffers for all 
Message Objects reside within the same 64KByte 
memory segment. The user is also responsible, on set- 30 
up, for specifying the size of the message buffer for each 
Message Object n. In particular, the user can specify 
the size of the message buffer for each particular Mes- 
sage Object n by programming the MnBSZ register 
associated with that Message Object n. The top location 35 
of the message buffer for each Message Object n is 
determined by the size of that message buffer as speci- 
fied in the corresponding MnBSZ register. 
[0057] The user can configure (program) the 
MnCTL register associated with each particular Mes- 40 
sage Object n in order to enable or disable that Mes- 
sage Object n, in order to define or designate that 
Message Object n as a Tx or Rx Message Object; in 
order to enable or disable automatic hardware assem- 
bly of fragmented Rx messages (i.e., automatic frag- 45 
mented message handling) for that Message Object n; 
in order to enable or disable automatic generation of a 
Message-Complete Interrupt for that Message Object n; 
and, in order to enable or not enable that Message 
Object n for Remote Iransmit Request (RTR) handling, so 
In CANopen and OSEK systems, the user must also ini- 
tialize the MnFCR register associated with each Mes- 
sage Object n. 

[0058] As previously mentioned, on set-up, the user 
must configure (program) the global GCTL register, ss 
whose bits control global parameters that apply to all 
Message Objects. In particular, the user can configure 
(program) the GCTL register in order to specify the 
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high-level CAL protocol (IT any) being used (e.g., 
DeviceNet, CANopen, or OSEK); in order to enable or 
disable automatic acknowledgment of CANopen 
Frames (CANopen auto-acknowledge); and, in order to 
specify which of two transmit (Tx) pre-arbitration 
schemes/policies is to be utilized (i.e., either Tx pre- 
arbitration based on CAN ID, with the object number 
being used as a secondary tie-breaker, or Tx pre-arbi- 
tration based on object number only). 

Receive Message Objects and the Receive Process 

[0059] During reception (i.e., when an incoming 
CAN Frame is being received by the XA-C3 microcon- 
troller 20), the CAN/CAL module 77 will store the incom- 
ing CAN Frame in a temporary (13-Byte) buffer, and 
determine whether a complete, error-free CAN frame 
has been successfully received. If it is determined that a 
complete, error-free CAN Frame has been successfully 
received, then the CAN/CAL module 77 will initiate 
Acceptance Filtering in order to determine whether to 
accept and store that CAN Frame, or to ignore/discard 
that CAN Frame. 

Acceptance Filtering 

[0060] In general, because the XA-C3 microcontrol- 
ler 20 provides the user with the ability to program sep- 
arate Match ID and Mask fields for each of the 32 
independent Message Objects, on an object-by-object 
basis, as described previously, the Acceptance Filtering 
process performed by the XA-C3 microcontroller 20 can 
be characterized as a "match and mask" technique. The 
basic objective of this Acceptance Rite ring process is to 
determine whether a Screener ID field of the received 
CAN Frame (excluding the "dont care" bits masked by 
the Mask field for each Message Object) matches the 
Match ID of any enabled one of the 32 Message Objects 
that has been designated a Receive Message Object If 
there is a match between the received CAN Frame and 
more than one Message Object, then the received CAN 
Frame will be deemed to have matched the Message 
Object with the lowest object number (n). 

Message Storage: 

[0061] Each incoming (received) CAN-Frame that 
passes Acceptance Filtering, will be automatically 
stored, via the DMA engine 38, into the message buffer 
for the Receive Message Object that particular CAN 
Frame was found to have matched. In an exemplary 
implementation, the message buffers for all Message 
Objects are contained in the XRAM 28. 

Message Assembly: 

[0062] In general, the DMA engine 38 will transfer 
each accepted CAN Frame from the 13-byte pre-buffer 
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to the appropriate message buffer (e.g., in the XRAM 
28), one word at a time, starting from the address 
pointed to by the contents of the MBXSR and MnBLR 
registers. Every time the DMA engine 38 transfers a 
byte or a word, it has to request the bus. In this regard, 
the MIF unit 30 arbitrates between accesses from the 
XA CPU Core 22 and from the DMA engine 38. In gen- 
eral, bus arbitration is done on an "alternate" policy. 
After a DMA bus access, the XA CPU Core 22 Will be 
granted bus access, if requested. After an XA CPU bus 
access, the DMA engine 38 will be granted bus access, 
if requested. (However, a burst access by the XA CPU 
Core 22 cannot be interrupted by a DMA bus access). 
[0063] Once bus access is granted by the MIF unit 
30, the DMA engine 38 will write data from the 13-byte 
pre-buffer to the appropriate message buffer location. 
The DMA engine 38 will keep requesting the bus, writ- 
ing message data sequentially to the appropriate mes- 
sage buffer location until the whole accepted CAN 
Frame is transferred. After the DMA engine 38 has suc- 
cessfully transferred an accepted CAN Frame to the 
appropriate message buffer location, the contents of the 
message buffer will depend upon whether the message 
that the CAN Frame belongs to is a non-fragmented 
(single frame) message or a fragmented message. 
Each case is described below: 

Non-Fragmented Messa ge Assembl y; 

[0064] For Message Objects that have been set up 
with automatic fragmented message handling disabled 
(not enabled - - i.e., the FRAG bit in the MnCTL register 
for that Message Object is set to '0'), the complete CAN 
ID of the accepted CAN Frame (which is either 11 or 29 
bits, depending on whether the accepted CAN Frame is 
a Standard or Extended CAN Frame) is written into the 
MnMIDH and MnMIDL registers associated with the 
Message Object that has been deemed to constitute a 
match, once the DMA engine 38 has successfully trans- 
ferred the accepted CAN Frame to the message buffer 
associated with that Message Object. This will permit 
the user application to see the exact CAN ID which 
resulted In the match, even if a portion of the CAN ID 
was masked for Acceptance Filtering. As a result of this 
mechanism, the contents of the MnMIDH and MnMIDL 
registers can change every time an incoming CAN 
Frame is accepted. Since the incoming CAN -Frame 
must pass through the Acceptance Filter before it can 
be accepted, only the bits that are masked out will 
change. Therefore, the criteria for match and mask 
Acceptance Filtering will not change as a result of the 
contents of the MnMIDH and MnMIDL registers being 
changed in response to an accepted incoming CAN 
Frame being transferred to the appropriate message 
buffer. 



Fragmented Message Assembly: 

[0065] For Message Objects that have been set up 
with automatic fragmented message handling enabled 

5 (i.e., with the FRAG bit in the MnCTL register for that 
Message Object set to 'I"), masking of the 11/29 bit 
CAN ID field is disallowed. As such, the CAN ID of the 
accepted CAN Frame is known unambiguously, and is 
contained in the MnMIDH and MnMIDL registers asso- 

io dated with the Message Object that has been deemed 
to constitute a match. Therefore, there is no need to 
write the CAN ID of the accepted CAN Frame into the 
MnMIDH and MnMIDL registers associated with the 
Message Object that has been deemed to constitute a 

is match. 

[0066] As subsequent CAN Frames of a frag- 
mented message are received, the new data bytes are 
appended to the end of the previously received and 
stored data bytes. This process continues until a com- 
20 plete multi-frame message has been received and 
stored in the appropriate message buffer. 
[0067] Under CAL protocols DeviceNet, CANopen, 
and OSEK, if a Message Object is an enabled Receive 
Message Object, and its associated MnCTL register 
25 has its FRAG bit set to T (i.e., automatic fragmented 
message assembly is enabled for that particular 
Receive Message Object), then the first data byte (Data 
Byte 1) of each received CAN Frame that matches that 
particular Receive Message Object will be used to 
30 encode fragmentation information only, and thus, will 
not be stored in the message buffer for that particular 
Receive Message Object. Thus, message storage for 
such "FRAG-enabled" Receive Message Objects will 
start with the second data byte (Data Byte 2) and pro- 
as ceed in the previously-described manner until a com- 
plete multi-frame message has been received and 
stored in the appropriate message buffer. This message 
storage format is illustrated in FIG. 11. The message 
handler hardware will use the fragmentation information 
40 contained in Data Byte 1 of each CAN Frame to facili- 
tate this process. 

[0068] Under the CAN protocol, if a Message 
Object is an enabled Receive Message Object, and its 
associated MnCTL register has its FRAG bit set to T 

45 (i.e., automatic fragmented message assembly is ena- 
bled for that particular Receive Message Object), then 
the CAN Frames-that match that particular Receive 
Message Object will be stored sequentially in the mes- 
sage buffer for that particular Receive Message Object 

so using the format shown in FIG. 1 2. 

[0069] When writing message data into a message 
buffer associated with a Message Object n, the DMA 
engine 38 will generate addresses automatically start- 
ing from the base address of that message buffer (as 

55 specified in the MnBLR register associated with that 
Message Object n). Since the size of that message 
buffer is specified in the MnBSZ register associated with 
that Message Object n, the DMA engine 38 can deter- 
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mine when it has reached the top location of that mes- 
sage buffer, if the DMA engine 38 determines that it has 
reached the top location of that message buffer, and 
that the message being written into that message buffer 
has not been completely transferred yet, the DMA 5 
engine 38 will wrap around by generating addresses 
starting from the base address of that message buffer 
again. Some time before this happens, a warning inter- 
rupt will be generated so that the user application can 
take the necessary action to prevent data loss. w 
[0070] The message handler will keep track of the 
current address location of the message buffer being 
written to by the DMA engine 38, and the number of 
bytes of each CAL message as it is being assembled in 
the designated message buffer. After an "End of Mes- 15 
sage" for a CAL message is decoded, the message 
handler will finish moving the complete CAL message 
and the Byte Count into the designated message buffer 
via the DMA engine 38, and then generate an interrupt 
to the XA CPU Core 22 indicating that a complete mes- 20 
sage has been received. 

[0071] Since Data Byte 1 of each CAN Frame con- 
tains the fragmentation information, it will never be 
stored in the designated message buffer for that CAN 
Frame. Thus, up to seven data bytes of each CAN 25 
Frame will be stored. After the entire message has been 
stored, the designated message buffer will contain all of 
the actual informational data bytes received (exclusive 
of fragmentation information bytes) plus the Byte Count 
at location 00 which will contain the total number of 30 
informational data bytes stored. 
[0072] It is noted that there are several specific user 
set-up/programming procedures that must be followed 
when invoking automatic hardware assembly of frag- 
mented OSEK and CANopen messages. These and 35 
other particulars can be found in the XA-C3 CAN Trans- 
port Layer Controller User Manual that is part of the par- 
ent Provisional Application Serial No. 60/154,022, the 
disclosure of which has been fully incorporated herein 
for all purposes. ao 



Transmit Message Objects and the Transmit Proc- 
ess 



[0073] In order to transmit a message, the XA appli- 45 
cation program must first assemble the complete mes- 
sage and store it in the designated message -buffer for 
the appropriate Transmit Message Object n. The mes- 
sage header (CAN ID and Frame Information) must be 
written into the MnMIDH, MnMIDL, and MnMSKH regis- so 
ters associated with that Transmit Message Object n. 
After these steps are completed, the XA application is 
ready to transmit the message. To initiate a transmis- 
sion, the object enable bit (OBJ_EN bit) of the MnCTL 
register associated with that Transmit Message Object n 55 
must be set, except when transmitting an Auto- Acknowl- 
edge Frame in CANopen. This will allow this ready-to- 
transmit message to participate in the pre-arbitration 



process. In this connection, / more than one message 
is ready to be transmitted (i.e., if more than one Trans- 
mit Message Object is enabled), a Tx Pre-Arbitration 
process will be performed to determine which enabled 
Transmit Message Object will be selected for transmis- 
sion. There are two Tx Pre-Arbitration policies which the 
user can choose between by setting or clearing the 
Pre_Arb bit in the GCTL register. 
[0074] After a Tx Message Complete interrupt is 
generated in response to a determination being made 
by the message handler that a completed message has 
been successfully transmitted, the Tx Pre-Arbitration 
process is "reset", and begins again. Also, if the "win- 
ning" Transmit Message Object subsequently loses 
arbitration on the CAN bus, the Tx Pre-Arbitration proc- 
ess gets reset and begins again. If there is only one 
Transmit Message Object whose OBJ_EN bit is set, it 
will be selected regardless of the Tx Pre-Arbitration pol- 
icy selected. 

[0075] Once an enabled Transmit Message Object 
has been selected for transmission, the DMA engine 38 
will begin retrieving the transmit message data from the 
message buffer associated with that Transmit Message 
Object, and will begin transferring the retrieved transmit 
message data to the CCB 42 for transmission. The 
same DMA engine and address pointer logic is used for 
message retrieval of transmit messages as is used for 
message storage of receive messages, as described 
previously. Further, message buffer location and size 
information is specified in the same way, as described 
previously. In short, when a transmit message is 
retrieved, it will be written by the DMA engine 38 to the 
CCB 42 sequentially. During this process, the DMA 
engine 38 will keep requesting the bus; when bus 
access is granted, the DMA engine 38 will sequentially 
read the transmit message data from the location in the 
message buffer currently pointed to by the address 
pointer logic; and, the DMA engine 38 will sequentially 
write the retrieved transmit message data to the CCB 
42. It is noted that when preparing a message for trans- 
mission, the user application must not include the CAN 
ID and Frame Information fields in the transmit message 
data written into the designated message buffer, since 
the Transmit (Tx) logic will retrieve this information 
directly from the appropriate MnMIDH, MnMIDL, and 
MnMSKH registers. 

[0076] The XA-C3 microcontroller 20 does not han- 
dle the transmission of fragmented messages in hard- 
ware. It is the user's responsibility to write each CAN 
Frame of a fragmented message to the appropriate 
message buffer, enable the associated Transmit Mes- 
sage Object for transmission, and wait for a completion 
before writing the next CAN Frame of that fragmented 
message to the appropriate message buffer. The user 
application must therefore transmit multiple CAN 
Frames one at a time until the whole multi-frame, frag- 
mented transmit message is successfully transmitted. 
However, by using multiple Transmit Message Objects 
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whose object numbers increase sequentially, and 
whose CAN IDs have been configured identically, sev- 
eral CAN Frames of a fragmented transmit message 
can be queued up and enabled, and then transmitted in 
order. 5 
[0077] To avoid data corruption when transmitting 
messages, there are three possible approaches: 

If the Tx Message Complete interrupt is enabled for 
the transmit message, the user application would 10 
write the next transmit message to the designated 
transmit message buffer upon receipt of the Tx 
Message Complete interrupt. Once the interrupt 
flag is set, it is known for certain that the pending 
transmit message has already been transmitted. 15 

Wait until the OBJ_EN bit of the MnCTL register of 
the associated Transmit Message Object clears 
before writing to the associated transmit message 
buffer. This can be accomplished by polling the 20 
OBJ_EN bit of the MnCTL register of the associ- 
ated Transmit Message Object. 

Clear the OBJ_EN bit of the MnCTL register of the 
associated Transmit Message Object while that 25 
Transmit Message Object is still in Tx Pre-Arbitra- 
tion. 

[0078] In the first two cases above, the pending 
transmit message will be transmitted completely before 30 
the next transmit message gets transmitted. For the 
third case above, the transmit message will not be 
transmitted. Instead, a transmit message with new con- 
tent will enter Tx Pre-Arbitration. 

[0079] There is an additional mechanism that pre- 35 
vents corruption of a message that is being transmitted. 
In particular, if a transmission is ongoing for a Transmit 
Message Object, the user will be prevented from clear- 
ing the OBJ_EN bit in the MnCTL register associated 
with that particular Transmit Message Object. 40 

CAK/CAL RELATED INTERRUPTS 

[0080] The CAN/CAL module 77 of the XA-C3 
microcontroller 20 is presently configured to generate 45 
the following five different Event interrupts to the XA 
CPU Core 22: 

Rx Message Complete 

Tx Message Complete so 
Rx Buffer Full 
Message Error 
Frame Error 

[0081] For single-frame messages, the "Message 55 
Complete" condition occurs at the end of the single 
frame. For multi-frame (fragmented) messages, the 
"Message Complete" condition occurs after the last 



frame is received and stored. Since the XA-C3 micro- 
controller 20 hardware does not recognize or handle 
fragmentation for transmit messages, the Tx Message 
Complete condition will always be generated at the end 
of each successfully transmitted frame. 
[0082] As previously mentioned, there is a control 
bit associated with each Message Object indicating 
whether a Message Complete condition should gener- 
ate an interrupt, or just set a "Message Complete Status 
Flag" (for polling) without generating an interrupt This is 
the INTJEN bit in the MnCTL register associated with 
each Message Object n. 

[0083] There are two 16-bit MMRs 40, MCPLH and 
MCPLL, which contain the Message Complete Status 
Flags for all 32 Message Objects. When a Message 
Complete (Tx or Rx) condition is detected for a particu- 
lar Message Object, the corresponding bit in the 
MCPLH or MCPLL register will be set. This will occur 
regardless of whether the INT_EN bit is set for that par- 
ticular Message Object (in its associated MnCTL regis- 
ter), or whether Message Complete Status Rags have 
already been set for any other Message Objects. 
[0084] In addition to these 32 Message Complete 
Status Flags, there is a Tx Message Complete Interrupt 
Flag and an Rx Message Complete Interrupt Flag, cor- 
responding to bits [1] and [0], respectively, of an MMR 
40 designated CANINTFLG, which will generate the 
actual Event interrupt requests to the XA CPU Core 22. 
When an End-of-Message condition occurs, at the 
same moment that the Message Complete Status Flag 
is set, the appropriate Tx or Rx Message Complete 
Interrupt flip-flop will be set provided that INT_EN = 1 for 
the associated Message Object, and provided that the 
interrupt is not already set and pending. 
[0085] Further details regarding the generation of 
interrupts and the associated registers can be found in 
the XA-C3 Functional Specification and in the XA-C3 
CAN Transport Layer Controller User Manual, both of 
which are part of the parent Provisional Application 
Serial No. 60/154,022, the disclosure of which has been 
fully incorporated herein for all purposes. 

MESSAGE BUFFERS 

[0086] As was previously described in detail herein- 
above, the XA-C3 microcontroller 20 supports up to 32 
separate and independent Message Objects r each of 
which is set-up or defined by virtue of the user (pro- 
grammer) configuring (programming) some or all of the 
eight MMRs 40 dedicated to that Message Object. In 
the XA-C3 microcontroller 20, each of the 32 Message 
Objects is assigned its own block of address space in 
data memory, which serves as its message buffer for 
data storage. The size and location of each message 
buffer is programmable, and thus, reconfigurable "on 
the fly" by the user/programmer. The message buffers 
can be positioned in any desired location within the 
overall data memory space addressable by the XA-C3 
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microcontroller 20, which is presently configured to be a 
16 Mbyte overall memory space. These message buff- 
ers can be located in the XRAM 28 and/or in any off- 
chip portion of the overall data memory space. 
-[0087] The location of the message buffer associ- s 
ated with each Message Object n is established by pro- 
gramming the MMR 40 designated MnBLR associated 
with that Message Object, i.e., by programming the 
Message n Buffer Location Register. The size of the 
message buffer associated with each Message Object w 
is established by programming the MMR 40 designated 
MnBSZ associated with that Message Object, i.e., by 
programming the Message n Buffer SiZe Register. In 
the XA-C3 microcontroller 20, allowable buffer sizes are 
2, 4, 8, 16, 32, 64, 128, or 256 bytes. Users can select is 
the size of each message buffer based on the antici- 
pated length of the incoming message, or they can con- 
serve memory by deliberately specifying smaller buffers 
at the expense of increased processor intervention to 
handle more frequent buffer-full conditions. In the XA- 20 
C3 microcontroller 20, Direct Memory Access (DMA) 
(i.e., the DMA engine 38) is used to enable the XA-C3 
CAN/CAL module 77 to directly access the 32 message 
buffers without interrupting the XA-C3 processor (CPU) 
core 22. 25 
[0088] The XA-C3 CAN/CAL module 77 uses the 
values programmed into the buffer size registers 
MnBSZ to reserve the designated number of bytes of 
storage for each Message Object n. For Receive Mes- 
sage Objects, this field is also used by logic in the XA- 30 
C3 CAN/CAL module 77 to calculate the total number of 
bytes that have actually been stored in the message 
buffers, and to identify when a buffer-full condition is 
reached. Each time a byte of data is stored in a mes- 
sage buffer associated with a Message Object n, the 35 
XA-C3 CAN/CAL module 77 concurrently accesses the 
MnBSZ and MnBLR registers associated with that Mes- 
sage Object Logic incorporated within the XA-C3 
CAN/CAL module 77 decodes the buffer size for that 
Message Object and compares the decoded buffer size 40 
to the address pointer to determine current byte count 
and available space left in that Message Objects mes- 
sage buffer. 

[0089] The present implementation of the XA-C3 
microcontroller 20 requires that all of the 32 message 45 
buffers reside within the same 64 Kbyte memory seg- 
ment (or "page"). The user may position the message 
buffers within any of the 256 pages in the overall XA-C3 
data memory space (i.e., 256 x 64 Kbytes = 1 6 Mbytes). 
Programming the locations of the message buffers is so 
accomplished in two steps. 

[0090] The first step is to program the page number 
in which all of the message buffers reside into the MMR 
40 designated as the MBXSR register, which is one of 
the CCB Registers depicted in FIG. 4. As was previ- 55 
ously described, the contents of this register are subse- 
quently used as the eight MSBs of address for all DMA 
accesses to any of the message buffers. This register 



also establishes the memory page in which the XRAM 
28 resides. 

[0091] The second step is to program the base 
address (16 bits) for each individual message buffer into 
the MnBLR associated with that message buffer. These 
1 6-bit address values initially specified by the user/pro- 
grammer constitute the base addresses of the 32 
respective message buffers within the 64 Kbyte memory 
page specified in the MBXSR register for all message 
buffers. It should be noted that the message buffers can 
be placed apart from one another, as there is no 
requirement that the message buffer space be continu- 
ous (i.e., that the message buffers reside in physically 
contiguous locations within the data memory space). 
Further, it should also be noted that some or all of the 
message buffers can be placed in off-chip memory, and 
others in the on-chip XRAM 28. In the XA-C3 microcon- 
troller 20, it is required that each message buffer start at 
a binary boundary for its size (i.e., the 8 LSBs must be 
zero for a 256-byte message buffer, the 7 LSBs must be 
zero for a 128-byte message buffer, etc.). 
[0092] DMA access to each of the message buffers 
is achieved by using the 8 bits stored in the MBXSR reg- 
ister as the 8 MSBs of the address of that message 
buffer, and the 16 bits stored in the MnBLR register for 
that message buffer as the 16 LSBs of the address of 
that message buffer. The base address initially pro- 
grammed by the user into the MnBLR register for that 
message buffer is the address of the first (bottom) loca- 
tion of that message buffer. When the first frame of a 
new receive message arrives, the CAN/CAL module 77 
hardware writes a semaphore code into this bottom 
location before beginning to store actual data bytes, 
starting at the next location in that message buffer. At 
the end of the new receive message (or when a buffer- 
full condition is detected), the CAN/CAL module 77 
hardware computes the total number of bytes actually 
stored in that message buffer, and writes this value into 
the bottom location of that message buffer. The proces- 
sor (i.e., the XA CPU Core 22) can then read this value 
and determine precisely how many additional bytes 
must be read and processed. 

[0093] Each time a new byte of data must be written 
to (for receive messages) or retrieve from (for transmit 
messages) a message buffer, the DMA engine 38 reads 
the MnBLR register for that message buffer in order to 
retrieve the current: address pointer for tbe-associated 
Message Object. The DMA engine 38 concatenates the 
8 MSBs stored in the global Message Buffer Segment 
Register (i.e., the MBXSR register) and the 16 LSBs 
stored in the MnBLR register for that message buffer to 
form a complete 24-bit message buffer address. The 
DMA engine 38 then passes this address to the Mem- 
ory Interface (MIF) unit 30, along with a flag indicating 
that the DMA engine 38 requires access to the memory. 
As soon as the current set of XA-C3 processor memory 
accesses are completed, the MIF unit 30 will initiate a 
memory read or write to the address provided by the 
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DMA engine 38, and then permit the DMA engine 38 to 
perform the required data transfer to/from the desired 
message buffer. DMA accesses are typically done two 
bytes at a time (i.e., as a 16-bit operation). However, 8- 
bit operations are employed when there is only a single 5 
byte to be transferred. 

[0094] As soon as the requested DMA operation is 
completed, the DMA engine 38 increments the 16-bit 
address value stored in the MnBLR register associated 
with that message buffer (by one or two, depending 10 
upon whether a one byte or two byte access was per- 
formed), and writes this value back into the MnBLR reg- 
ister for that message buffer. Thus, the MnBLR 
registers, along with the associated increment logic 
within the DMA engine 38, effectively function as a set 15 
of 32 binary "counters". Thus, at any given time, each 
MnBLR register contains the address which will be used 
for the next data access to the message buffer associ- 
ated with the Message Object n. In this manner, the 
MnBLR register for each message buffer serves as an 20 
address-pointer. These address-pointer fields are also 
readable at any time by the processor under software 
control. 

[0095] The above-described approach to message 
storage also provides an extremely quick and efficient 25 
means of freeing up a message buffer when a message 
completes or when a message buffer is full. The soft- 
ware can respond to a message-complete interrupt or a 
buffer-full interrupt by simply repositioning the mes- 
sage-buffer space for that particular Message Object to 30 
somewhere else in the message buffer memory space. 
This is accomplished by performing a single write oper- 
ation to modify the buffer base-address specified in the 
appropriate MnBLR register (i.e., "address-pointer"). 
This is essentially the extent of a very short interrupt 35 
handling routine. These interrupts must be handled 
quickly because the message buffer must be freed-up 
for subsequent message reception. Interrupt response 
is particularly critical if many completed messages are 
stacked up and need to be dealt with at once. Once this 40 
buffer repositioning is accomplished, the hardware is 
immediately ready to receive a new message over that 
Message Object "channel" (or, the continuation of the 
current message, in the case of a buffer-full interrupt). 
The memory space that was previously designated as 45 
the message buffer for that Message Object n still con- 
tains the previously-received message data, but this 
space now becomes just part of the long-term data 
memory space. The message information stored in this 
long-term data memory space can then be processed so 
by the software at its leisure. 

[0096] This same buffer repositioning technique 
can be employed for Transmit Messages to facilitate 
fragmentation. Unlike the receive case, the XA-C3 
CAN/CAL Module 77 does not automatically assemble ss 
fragmented outgoing messages. It is incumbent upon 
the software to "load" a new message frame each time 
the previous frame is transmitted. Using the XA-C3 



microcontroller 20 message storage scheme, however, 
the software can construct an entire fragmented mes- 
sage prior to enabling transmission. As each frame is 
transmitted, the processor (XA CPU Core 22) only 
needs to reposition the buffer (again, using a single 
write operation) to point to the location of the next frame. 
This is much faster than competing devices, which 
require the processor to move up to 13 bytes of data 
from memory to a dedicated transmit buffer. 
[0097] It will be appreciated that with the above- 
described message buffer scheme of the present inven- 
tion, each message buffer can be regarded as a sepa- 
rate FIFO having an independently programmable 
buffer length, which provides a revolutionary approach 
to storing sequential messages of varying lengths with- 
out any CPU intervention. 

THE PRESENT INVENTION 

[0098] As described hereinabove, because the XA- 
C3 microcontroller 20 provides the user with the ability 
to program separate Match ID and Mask fields for each 
of the 32 independent Message Objects, on an object- 
by-object basis, the Acceptance Filtering process per- 
formed by the XA-C3 microcontroller 20 can be charac- 
terized as a "match and mask" technique. The basic 
objective of this Acceptance Filtering process is to 
determine whether a Screener ID field of the received 
CAN Frame (excluding the "don't care" bits masked by 
the Mask field for each Message Object) matches the 
Match ID of any enabled one of the 32 Message Objects 
that has been designated a Receive Message Object If 
there is a match between the received CAN Frame and 
more than one Message Object, then the received CAN 
Frame will be deemed to have matched the Message 
Object with the lowest object number (n). 
[0099] In accordance with the present invention, 
Acceptance Filtering is performed as follows by the XA- 
C3 microcontroller 20: 

[0100] A Screener ID field is extracted from the 
incoming (received) CAN Frame. In this regard, the 
Screener ID field that is assembled from the incoming 
bit stream is different for Standard and Extended CAN 
Frames. In particular, as is illustrated in FIG. 9, the 
Screener ID field for a Standard CAN Frame is 28 bits, 
consisting of 1 1 CAN ID bits extracted from the header 
of the received CAN Frame + 2x8 (1 6) bits from the first 
and second data bytes (Data Byte 1 and Data Byte 2) of 
the received CAN Frame + the IDE bit Thus, the user is 
required to set the Msk1 and MskO bits in the Mask Field 
(MnMSKL register) for Standard CAN Frame Message 
Objects, i.e., to "dont care". In addition, in many appli- 
cations based on Standard CAN Frames, either Data 
Byte 1 , Data Byte 2, or both do not participate in Accept- 
ance Filtering. In those applications, the user must also 
mask out the unused Data Byte(s). The IDE bit is not 
maskable. As is illustrated in FIG. 10, the Screener ID 
field for an Extended CAN Frame is 30 bits, consisting 
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of 29 CAN ID bits extracted from the header of the 
incoming CAN Frame + the IDE bit. Again, the IDE bit is 
not maskable. 

[0101] The assembled Screener ID field of the 
received CAN Frame is then sequentially compared to 5 
the corresponding Match ID values specified in the 
MnMIDH and MnMIDL registers for all currently enabled 
Receive Message Objects. Of course, any bits in the 
Screener ID field that are masked by a particular Mes- 
sage Object are not included in the comparison. That is, io 
if there is a T in a bit position of the Mask field specified 
in the MnMSKH and MnMSKL registers for a particular 
Message Object, then the corresponding bit position in 
the Match ID field for that particular Message Object 
becomes a "donl care", i.e., always yields a match with is 
the corresponding bit of the Screener ID of the received 
CAN Frame. 

[0102] If the above comparison process yields a 
match with more than one Message Object, then the 
received CAN Frame will be deemed to have matched 20 
the Message Object having the lowest object number 
(n). 

[0103] As was described hereinabove, each incom- 
ing (received) CAN Frame that passes Acceptance Fil- 
tering will be automatically stored, via the DMA engine 25 
38, into the message buffer for the Receive Message 
Object that particular CAN Frame was found to have 
matched. 

[0104] Although the present invention has been 
described in detail hereinabove in the context of a spe- 30 
cific preferred embodiment/implementation, it should be 
clearly understood that many variations, modifications, 
and/or alternative embodiments/implementations of the 
basic inventive concepts taught herein which may 
appear to those skilled in the pertinent art will still fall 35 
within the spirit and scope of the present invention, as 
defined in the appended claims. 

Claims 

40 

1. A CAN device that supports a plurality n of mes- 
sage objects, comprising: 

a plurality of registers associated with each 
message object, including at least one object 45 
match ID register that contains a multi-bit 
object match ID field, and at least one -object 
mask register that contains a multi-bit object 
mask field; 

a CAN/CAL module that processes incoming so 
messages, wherein the CAN/CAL module: 
assembles a multi-bit screener ID from 
"selected bits of each incoming message to be 
acceptance filtered; 

compares the bits comprising the screener ID 55 
with corresponding bits of the object match ID 
field associated with each of at least desig- 
nated ones of the plurality n of message 
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objects, disregarding any bits of each object 
match ID field that are masked by correspond- 
ing bits of the associated object mask field; 
and, 

determines whether any of the comparisons 
results in a match; 

wherein any selected one or more bits of the 
object match ID field associated with each of 
the plurality n of message objects can be set to 
T or '0', and any selected one or more bits of 
the object mask field associated with each of 
the plurality n of message objects can be set to 
T or 'C in order to mask any selected one or 
more bits of the associated object match ID 
field, whereby the combination of the object 
match ID field and the object mask field associ- 
ated with each of the plurality n of message 
objects comprises a fully programmable match 
and mask filter; and, 
wherein n £ 3. 

2. The CAN device as set forth in Claim 1 , wherein: 

a received message to be acceptance filtered 
comprises a standard CAN frame; and, 
the screener ID field comprises 11 bits of a 
CAN ID field of a header portion of the stand- 
ard CAN frame, 8 bits of a first data byte of the 
standard CAN frame, 8 bits of a second data 
byte of the standard CAN frame, two dont care 
bits, and an IDE bit. 

3. The CAN device as set forth in Claim 2, wherein the 
IDE bit is not maskable, and the two dont care bits 
are required to be masked. 

4. The CAN device as set forth in Claim 1 , wherein: 

a received message to be acceptance filtered 
comprises an extended CAN frame; and, 
the screener ID field comprises 29 bits of a 
CAN ID field of a header portion of the stand- 
ard CAN frame, and an IDE bit 

5. The CAN device as set forth in Claim 4, wherein the 
IDE bit is not maskable. 

6. The CAN device as set forth in Claim 1 , wherein the 
CAN/CAL module has the capability to perform 
acceptance filtering on incoming messages com- 
prising either standard or extended CAN frames. 

7. The CAN device as set forth in Claim 1 , wherein the 
plurality of registers further include a control regis- 
ter associated with each message object, wherein 
the control register associated with each message 
object contains an object enable field that is pro- 
grammable for the purpose of enabling or disabling 
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the associated message object. 



8. The CAN device as set forth in Claim 7, wherein the 
control register associated with each message 
object further contains an object designation field 
that is programmable for the purpose of designating 
the associated message object as a receive or 
transmit message object, whereby the designated 
ones of the plurality n of message objects comprise 
all message objects that have been enabled and 
designated as a receive message object 

9. A CAN microcontroller that supports a plurality n of 
message objects, comprising: 

a processor core that runs CAN applications; 
a data memory space; 

a plurality of message buffers associated with 
respective ones of the message objects, the 
plurality of message buffers being located in 
the data memory space; 
a plurality of registers associated with each 
message object, including at least one object 
match ID register that contains a multi-bit 
object match ID field, and at least one object 
mask register that contains a multi-bit object 
mask field; 

a CAN/CAL module that processes incoming 
messages, wherein the CAN/CAL module: 
assembles a multi-bit screener ID from 
selected bits of each incoming message to be 
acceptance filtered; 

compares the bits comprising the screener ID 
with corresponding bits of the object match ID 
field associated with each of at least desig- 
nated ones of the plurality n of message 
objects, disregarding any bits of each object 
match ID field that are masked by correspond- 
ing bits of the associated object mask field; 
and, 

determines whether any of the comparisons 
results in a match; 

a DMA engine that enables the CAN/CAL mod- 
ule to directly access the message buffers with- 
out interrupting the processor core; 
wherein an incoming message for which a 
match is detected is stored by the DMA engine 
in the message buffer associated with the 
matching message object; 
wherein any selected one or more bits of the 
object match ID field associated with each of 
the plurality n of message objects can be set to 
T or '0', and any selected one or more bits of 
the object mask field associated with each of 
the plurality n of message objects can be set to 
T or *0' in order to mask any selected one or 
more bits of the associated object match ID 
field, whereby the combination of the object 
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match ID field and the object mask field associ- 
ated with each of the plurality n of message 
objects comprises a fully programmable match 
and mask filter; and, 
wherein n £ 3. 

10. In a CAN device that supports a plurality n of mes- 
sage objects each of which has an associated mes- 
sage buffer, at least one associated match ID 
register, and at least one associated mask register, 
a method for acceptance filtering incoming CAN 
frames, the method including the steps of: 

programming the at least one match ID register 
associated with each of at least designated 
ones of the message objects by selectively set- 
ting each of the bits in a multi-bit match ID field 
contained therein to T or '0'; 
programming the at least one mask register 
associated with each of the at least designated 
ones of the message objects by selectively set- 
ting each of the bits in a multi-bit mask field 
contained therein to T or '0*; 
extracting a multi-bit screener ID field from a 
received CAN frame; 

comparing the extracted screener ID field to 
the multi-bit match ID field stored in the at least 
one match ID register associated with each of 
the at least designated ones of the message 
objects, excluding from the comparison any 
bits of the match ID field masked by corre- 
sponding bits of the associated mask field 
stored in the at least one associated mask reg- 
ister; and, 

if a match if found as a result of the comparing 
step, storing data bytes of the received CAN 
frame in the message buffer associated with 
the matching message object; 
wherein n £ 3. 
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(54) A CAN device featuring advanced Can filtering and message acceptance 



(57) A CAN device that supports a plurality n (where 
n>3) of message objects, including a plurality of regis- 
ters associated with each message object, including at 
least one object match ID register that contains a multi- 
bit object match ID field, and at least one object mask 
register that contains a multi-bit object mask field; and, 
a CAN/CAL module that processes incoming mes- 
sages. The CAN/CAL module assembles a multi-bit 
screener ID from selected bits of each incoming mes- 
sage to be acceptance filtered, compares the bits com- 
prising the screener ID with corresponding bits of the 
object match ID field associated with each of at least 
designated ones of the plurality n of message objects, 
disregarding any bits of each object match ID field that 
are masked by corresponding bits of the associated 
object mask field, and then determines whether any of 
the comparisons results in a match. Any selected one or 
more bits of the object match ID field associated with 
each of the plurality a of message objects can be set to 
*1 ' or '0', and any selected one or more bits of the object 
mask field associated with each of the plurality n of 
message objects can be set to 'V or '(V in order to mask 
any selected one or more bits of the associated object 
match ID field, whereby the combination of the object 
match ID field and the object mask field associated with 
each of the plurality n of message objects constitutes a 
fully programmable match and mask filter. The 
CAN/CAL module has the capability to perform accept- 
ance filtering on incoming messages constituting either 



standard or extended CAN frames. If more than one 
match is detected, a lowest-numbered (or, alternatively, 
highest-numbered) one of the message objects is des- 
ignated to be the matching message object. 
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